Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add continuous deployment workflow for PyPI publication #34

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

LourensVeen
Copy link
Collaborator

Here's a PR with a Continuous Deployment workflow that should automatically build packages and push them to PyPI every time a GitHub release is made, as described in #33.

Besides the workflow, this requires some set-up to get PyPI and GitHub to work together. This used to be done using a long-lived access token, which PyPI would generate and which you would then put into GitHub as a secret, but that's been succeeded by a new system called OpenID.

If I get it right, this has GitHub log in to PyPI using its own credentials, and then it hands PyPI a signed statement that it's running a particular workflow. PyPI verifies that it's really talking to GitHub and that the statement was signed by it, and then gives GitHub a temporary token, essentially a cookie. This is then used by the rest of the workflow to push the packages. As a result, there are no long-lived tokens that can be leaked. (Except for a certificate or a private key or something at GitHub, but that's easier to secure.) All this is built into the pypa/gh-action-pypi-publish action.

There's a second security feature, which is the use of a GitHub environment. I'm not sure exactly what that adds if you're the only one with access to the repository, but it allows you to set rules on whether and when a workflow runs, which makes it harder for people with commit but not admin access to do something malicious. I've linked the documentation below and leave it to you to set this up in just the way you want.

There's a lot of documentation on all this, so I've dug through it and found the relevant parts and put together some instructions. Untested but after careful reading this should at least be pretty close to working.

Create an Actions environment on GitHub

Documentation

  • Follow the instructions to create an environment
    It should be named pypi as that's what the workflow refers to. You can set up rules as you like, perhaps mark yourself as a "Required reviewer" so that others with access to the repository cannot change e.g. setup.py and run it without your permission. No secrets are needed, because we're using OpenID.

Set up PyPI

Documentation

  • Make an account on PyPI, if you don't have one
  • Click on your account name at the top right and select "Your projects" in the menu
  • Click "Publishing" in the menu on the left
    This will let you "Add a new pending publisher", which we need to do because we don't have a project yet. This deviates slightly from the documentation linked above, which is for if you already have PyPI releases.
  • Choose the GitHub tab, fill out the following values, and click Add:
    • PyPI Project Name: transiflow
    • Owner: BIMAU
    • Repository name: transiflow
    • Workflow name: cd.yaml
    • Environment name: pypi

PyPI will now check that any request to publish will come from GitHub, and that GitHub claims to be running the specified workflow. And it will automatically create a transiflow project on the first release.

Make a release

If you now make a release on GitHub, the workflow should run, building the packages (source and wheel) and publishing them on PyPI.

For subsequent releases, you'll want to update the version both in setup.cfg and in doc/conf.py, there's no automation around that in this PR.

Copy link
Contributor

@Sbte Sbte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for all of the documentation! I'll work on the actions I need to take later and then merge the PR. I just had one question (see above or below).

@@ -5,6 +5,7 @@ on:
branches: [ master ]
pull_request:
branches: [ master ]
workflow_call:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just to support uses: above?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you need to add that apparently to make it so that you can call the workflow from another one. It's called a reusable workflow: https://docs.github.com/en/actions/using-workflows/reusing-workflows

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants